Automatic system for updating data

ABSTRACT

An automatic gateway that runs as an HTML solution and is capable of automatically generating service requests in response to a condition precedent for service by an On-Line Transaction Processing (OLTP) style application running on an enterprise server. The OLTP server provides a result which is utilized by the automatic gateway to update a data presentation. The services on the OLTP system are designed to accomplish a specific task, for example, update the schedules and pricing of an airline. In a preferred embodiment, the OLTP system is X/Open compliant. The users of the system can access the updated data presentation without further communication with the OLTP enterprise server.

CROSS REFERENCE TO CO-PENDING APPLICATIONS

The present application is related to U.S. patent application Ser. No.______, filed ______, entitled “AN AUTOMATED DEVELOPMENT SYSTEM FORDEVELOPING APPLICATIONS THAT INTERFACE WITH BOTH DISTRIBUTED COMPONENTOBJECT MODEL (DCOM) AND ENTERPRISE SERVER ENVIRONMENTS”, and applicationSer. No. ______, filed ______, entitled “A COMMON GATEWAY WHICH ALLOWSAPPLETS TO MAKE PROGRAM CALLS TO OLTP APPLICATIONS EXECUTING ON ANENTERPRISE SERVER”, both of which are assigned to the assignee of thepresent invention and incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a communications gateway for providingaccess to data generated by an enterprise server application from aDistributed Component Object Model (DCOM) environment, and morespecifically, to a technique for automatically updating certain data bya call to the Transaction Processing (OLTP) Enterprise ServerApplication such that the requested data is available to the userwithout the need for a further service request of the enterprise server.

2. Description of the Prior Art

The methods by which companies conduct business with their customers areundergoing fundamental changes, due in large part to World Wide Webtechnology. In addition, the same technology that makes a companyaccessible to the world, may be used on internal company networks forconducting operational and administrative tasks.

One of the technologies underlying the World Wide Web is the prospect ofusing component software technology—the idea of breaking large, complexsoftware applications into a series of pre-built and easily developed,understood, and changed software modules called components—as a means todeliver software solutions much more quickly and at a lower cost(source: DCOM: A Business Overview, online athttp://www.microsoft.com/ntserver/guide/dcom.asp). The goal is toachieve economies of scale for software deployment across the industry.

A component architecture for building software applications will enablethis by: 1) speeding development—enabling programmers to build solutionsfaster by assembling software from pre-built parts; 2) loweringintegration costs—providing a common set of interfaces for softwareprograms from different vendors means less custom work is required tointegrate components into complete solutions; 3) improving deploymentflexibility—making it easier to customize a software solution fordifferent areas of a company by simply changing some of the componentsin the overall application; and 4) lowering maintenance costs—isolatingsoftware function into discreet components provides a low-cost,efficient mechanism to upgrade a component without having to retrofitthe entire application.

A distributed component architecture applies these benefits across abroader scale of multiuser applications. The Distributed ComponentObject Model (DCOM), developed by Microsoft Corporation, has severalstrengths that make it a key technology for achieving this. Because itis an ActiveX technology, DCOM works natively with Internet technologieslike TCP/IP, the Java language, and the HTTP network protocol, providing“object glue” that will enable business applications to work across theWeb. DCOM is also an open technology that runs on multiple platforms.

DCOM has its roots in Microsoft's object technology, which has evolvedover the last decade from DDE (Dynamic Data Exchange, a form ofmessaging between Windows programs), OLE (Object Linking and Embedding,embedding visual links between programs within an application), COM (theComponent Object Model, used as the basis for all object binding), andActiveX (COM enabled for the Internet). As stated earlier, applicationsbuilt from components are simply easier to debug and evolve than large,monolithic applications.

The logical boundary for component applications is no longer on a singlemachine. Businesses want to leverage the benefits of componentdevelopment across a broader set of shared applications that operate onmultiple machines. These types of applications are referred to as“three-tier” or “n-tier” applications, where “tiers” of applicationlogic, presentation services, business services, and informationretrieval and management services, are broken into different componentsthat can communicate directly with each other across a network. To theend user, these applications appear as a seamless extension of theirexisting desktop environment.

The simplicity, ubiquity, and industry momentum of standard Internetprotocols like HTTP make it an ideal technology for linking componentstogether for applications that span machine boundaries. HTTP is easy toprogram, is inherently cross-platform, and supports an accessible,universal naming service. Much of the excitement around the Javalanguage derives from its potential as a mechanism to build distributedcomponent applications on the Internet. In addition to Java support,DCOM enables components written in other languages, including C, COBOL,Basic, and Pascal, to communicate over the Internet, providing a growthpath for existing applications to support Web technology.

As distributed component architectures, such as DCOM, are making theirmark as a technology that enables software components to communicatedirectly with each other across networks, many businesses have a wealthof information that is managed by prior art data base management systemssuch as DMS, RDMS, DB2, Oracle, Ingres, Sybase, Informix, and manyothers. In addition, many of the database management systems areavailable as resources in a larger transaction processing system.

One key to the future success of a business may lie in its ability tocapitalize on the ability to interconnect a distributed componentarchitecture, such as DCOM, with existing enterprise On-line TransactionProcessing (OLTP) systems. It defeats the two main goals ofcomponent-based development, fast time-to-market and lower developmentcosts, if companies are forced to “hand code” into their componentapplications the mission critical services that are required for onlineproduction systems.

However, there are certain types of applications wherein it is expectedthat a large number of users will request access to the same databetween actual changes to the data. In such cases, it may become quitewasteful to permit each user to access the enterprise server forcomputation of the same data.

SUMMARY OF THE INVENTION

The present invention overcomes many of the disadvantages associatedwith the prior art by providing a gateway mechanism whereby automaticservice requests are generated within a Distributed Component ObjectModel (DCOM) environment for service by an enterprise On-LineTransaction Processing (OLTP) system to update data for futurereference. Thus, the gateway of the present invention provides updated,standardized data to a user in the DCOM client/server environment usingthe full resources of the enterprise server. Yet the services on theOLTP system are accessed to update the data at intervals associated withthe much slower rate of change of the data rather than the rapid rate ofrequests to access the data by a potentially large number of users.

A typical application for which the subject invention is particularlyefficient involves the flight schedules and pricing of scheduled airlinetravel. The airline may choose to update the data at certain intervals(e.g., weekly). Yet during each week, between updates, the schedulingand pricing information may be accessed many thousands of times. Thepresent invention requests the enterprise server to update the scheduleand pricing information once at a particular point during the week.Subsequently, individual users may readily access the updated schedulesand prices in a “canned” format without the need for the enterpriseserver to redo the computations for each access request.

Each automatic update service request is designed to accomplish aspecific task. In a preferred embodiment, the OLTP system is X/Opencompliant. When an automatic OLTP request is generated by the gateway,the service request containing the service call and the appropriate setof input parameters is sent to as a buffer to the communicationsprogram, which in a preferred embodiment is the Open/OLTP HTPic program.The communications program passes the input buffer to the enterprisenode for processing by the requested service.

After the OLTP system services the request, a response is passed backvia an output buffer to the AutoGate Gateway, which updates theappropriate HTML files on the NT Server. As DCOM users request access tothe data, the DCOM Server provides the updated data without the need torequest further service from the OLTP enterprise server.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects of the present invention and many of the attendantadvantages of the present invention will be readily appreciated as thesame becomes better understood by reference to the following detaileddescription when considered in connection with the accompanyingdrawings, in which like reference numerals designate like partsthroughout the figures thereof and wherein:

FIG. 1 is a functional block diagram of an exemplary computingenvironment in which the present invention could be used to makeautomatic service requests of an enterprise based transaction processingsystem interoperable with a PC/Workstation based requester;

FIG. 2A is a functional block diagram of a generalized WebTxenvironment;

FIG. 2B is a functional block diagram of WebTx components utilizedwithin a Microsoft NT environment;

FIG. 3 is a diagram showing the relationship of the key softwarecomponents which allow DCOM clients to access enterprise applicationsfor non-automatic updates;

FIG. 4 is an illustration of the software environment;

FIG. 5 is a flow diagram illustrating how an automatic request is issuedto an enterprise OLTP enterprise application;

FIG. 6 is a flow diagram illustrating how to set up an automatic updateapplication; and

FIG. 7 is a flow diagram showing an automatic service request to updatedata within the DCOM environment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The detailed descriptions which follow are presented largely in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art.

An algorithm is here, generally, conceived to be a self-consistentsequence of steps leading to a desired result. These steps are thoserequiring physical manipulations of physical quantities. Usually, thoughnot necessarily, these quantities take the form of electrical ormagnetic signals capable of being stored, transferred, combined,compared, and otherwise manipulated. It proves convenient at times,principally for reasons of common usage, to refer to these signals asbits, values, elements, symbols, characters, terms, numbers or the like.It should be kept in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities.

Furthermore, the manipulations performed are often referred to in terms,such as adding or comparing, which are commonly associated with mentaloperations performed by a human operator. No such capability of a humanoperator is necessary, or desirable in most cases, in any of theoperations described herein which form part of the present invention;the operations are machine operations. Useful machines for performingthe operations of the present invention include general purpose digitalcomputers or other similar devices. In all cases, it should be kept inmind the distinction between the method operations in operating acomputer and the method of computation itself. The present inventionrelated to method steps for operating a computer in processingelectrical or other (e.g., mechanical, chemical) physical signals togenerate other desired physical signals.

The present invention also relates to apparatus for performing theseoperations. This apparatus may be specially constructed for the requiredpurposes or it may comprise a general purpose computer as selectivelyactivated or reconfigured by a computer program stored in the computer.The algorithms present herein are not inherently related to a particularcomputer system or other apparatus. In particular, various generalpurpose computer systems may be used with computer programs written inaccordance with the teachings of the present invention, or it may provemore convenient to construct more specialized apparatus, to perform therequired method steps. The required structure for such machines will beapparent from the description given below.

FIG. 1 is a functional block diagram of an exemplary computingenvironment in which an enterprise based transaction processing systemis interoperable with a PC/Workstation based requester. A plurality ofPC/Workstations, designated as Clients 10, 12, 14 and 16 are coupled toa Server 18 via Network 20. The Network 20 may be an internal local areanetwork or the Internet.

Each of the Clients 10, 12, 14 and 16, is a PersonalComputer/Workstation having operating system software and applicationsoftware designed to provide Graphical User Interface (GUI) andcommunications capabilities which enable the Client to communicate withan associated Server application 18 via a Network 20.

The Workstation Server System 50 may be any class of machine(s) whichare capable of running a Server application 18 along with a DistributedTransaction Processor 54. The Transaction Processing system 54 isdesignated as Distributed to make clear that a transaction is formattedon the Workstation Server System 50 and forwarded to the EnterpriseServer system 52 for processing.

The exemplary Enterprise Server System 52 is a 2200 Series dataprocessing system from Unisys and also includes a DistributedTransaction Processing System 56. The Distributed Transaction ProcessingSystem 56 is intended to encompass the same functionality as amonolithic transaction processing system, however, it is designated asDistributed to be compatible with the Distributed Transaction ProcessingSystem 54. The exemplary Distributed Transaction Processing Systems 54and 56 are intended to encompass transaction manager software, such asOpen/OLTP Transaction Manager software from Unisys, and user implementedOpen/OLTP services. The Distributed Transaction Processing System 54 andthe Distributed Transaction Processing System 56 are coupled via Network58. Preferably, the network interface for Network 58 is separate fromthe network interface for Network 20.

The Distributed Transaction Processing System 56 serves data from theDatabase 28 to the Transaction Clients 30, 32, 34 and 36. TheTransaction Clients 30, 32, 34 and 36 are coupled to the DistributedTransaction Processing System 56 via line 38, of which the underlyingtechnology is driven by the application of the Distributed TransactionProcessing System 56.

The Transaction Gateway Client 40 allows the Server 18 to interoperatewith the Transaction Processing System. When a Client 10, 12, 14 or 16selects an enterprise based service, the request is routed to the Server18, which in turn routes the request to the Transaction Gateway Client40. The Transaction Gateway Client 40 determines the requested serviceand forwards the necessary information to the Distributed TransactionProcessing System 54 and 56. The Distributed Transaction ProcessingSystem 54 and 56 processes the request against the Database 28 accordingto the specified request (e.g., select, update, delete). The DistributedTransaction Processing System 54 and 56 returns data and/or statusinformation to the Transaction Gateway Client 40, which in turn formatsthe data in an appropriate manner for the Server 18. The Server 18 thenreturns the information to the requesting Client 10, 12, 14 and 16.

FIG. 2A is a functional block diagram of a generalized WebTxenvironment. In general, WebTx is middleware in a client/servercomputing environment which accepts requests from the client side androutes the requests to the correct place on the server side, then passesa response from the server side back to the client side. In the contextof the present invention, this is really an HTML solution.

The WebTx environment, as utilized in the present invention, iscomprised of several components, including a Monitor 201, a Web ServerExtension 237, one or more Gateways 213, 217, 221, and 207, the WebViewCcompiler 290, and a set of libraries 288.

The WebTx Monitor 201 communicates with the Web Server Extension 237 viainterface 203, and a Gateway 207 via interface 209. The Monitor 201functions as the WebTx administrative tool. One function of the Monitor201 is to start and stop the gateways 207, 213, 217, and 221, as needed.Within a Unix environment, the WebTx monitor module is known as WebMon,while under the Windows NT environment, the WebTx monitor module isknown as WtxSvc.

The WebTx Web Server Extension component 237, is a run-time extension ofthe Web Server 235 (such as Netscape FastTrack, Netscape Enterprise, orMicrosoft IIS). The function of the Web Server Extension 237 is tointercept requests intended for WebTx 218, and instead route therequests to the Gateways 207, 213, 217, and 221. The Web ServerExtension 237 will also interpret the response from the Gateways, androute the reply. The Web Server Extension is connected to the Gateways213, 217, 221 and 207 via interfaces 211, 215, 219 and 205. The WebServer Extension is connected to the Monitor 201 via interface 203, anHTML requestor component 224 via interface 228, and a Java Applet 226via interface 234.

The Gateways 213, 217, 221 and 207 perform tasks which are grouped intoconceptual areas. The Gateways 213, 217, 221 and 207 receive requestsfrom the Web Server Extension 237 or from the Applications 212 and takewhatever action is necessary to fulfill the request. This typicallyinvolves transforming a request (such as a URL from a Web Browser orremote procedure calls RPC's from a DCOM client) into a format which isunderstandable by a Distributed Transaction Processing System such as aUnisys 2200 Enterprise System 200. The Gateways 213, 217, 221 and 207also transform data returned from the Distributed Transaction ProcessingSystem 200 into a formatted response which is returned to the requester.

As explained in more detail below, one of the gates also makes theautomatic service requests associated with the present invention. Inthis manner, data updates are made utilizing these automatic servicerequests of the enterprise server. The updated data is produced forsubsequent client requests without the need for further communicationwith the enterprise server.

The WebViewC compiler 290 is used in conjunction with specific Gatewayimplementations, such as ViewGate, TUXGate, and JGate. The WebViewCcompiler 290 compiles Open/OLTP view files generated on the OLTPenterprise system to create WebTx view files (.wv) and HTML files(.html). The WebViewC compiler is a free-standing component with nodirect communication to any of the other components within the WebTxenvironment.

Other WebTx Components include libraries 288 such as the SoftwareDevelopment Kit (SDK) libraries, which provide framework and functionsfor building Custom Gateways. The SDK is specifically designed to allowcustomers to build their own gateways. Another type of library presentwithin the WebTx system are Java Class Libraries, which provide classdefinitions for building JavaGate compatible applets.

Another tool 290 that may exist as a WebTx component is DGateAce.DGateAce is analogous to WebViewC, and is used specifically inconjunction with DGate, as part of the Unisys Pathmate system. DGateAceis further described in a co-pending application entitled, “AN AUTOMATEDDEVELOPMENT SYSTEM FOR DEVELOPING APPLICATIONS THAT INTERFACE WITH BOTHDISTRIBUTED COMPONENT OBJECT MODEL (DCOM) AND ENTERPRISE SERVERENVIRONMENTS”.

Unix WebTx uses Inter-Process Communications (IPC) objects such assemaphores, shared memory, message queues and signals, while NT WebTxuses IPC objects such as handles, pipes, mutexes, and events.

FIG. 2B is a functional block diagram of WebTx components utilizedwithin a Microsoft NT environment. This figure shows specific Gatewayimplementations within the Windows NT node. The SimpleGate Gateway 236is specifically utilized as a test tool. It merely echoes a request. TheTUXGate Gateway 240 provides generalized access to OLTP services throughBEA TUXEDO 266. BEA TUXEDO acts as the hub for a distributed enterpriseand Internet 3-tier applications. It provides an open environment thatsupports a wide variety of clients, databases, networks, legacy systems,and communications options. The FileGate Gateway 244 works inconjunction with a specific OLTP service to access textual files on theUnisys 2200 node. ViewGate 248 provides generalized access to OLTPservices on the Unisys 2200 note (specifically HTML output). JGate 252provides generalized Java applet access to OLTP services on the Unisys2200 node. The DGate Gateway 256 provides generalized DCOM access toOLTP services on the Unisys 2200 node. The MapperGate Gateway 260provides generalized access to Mapper applications within the MicrosoftWindows NT environment. The AutoGate Gateway, shown at 264, willautomatically generate the service requests to the Unisys 2200 node toupdate the appropriate data within the NT Node. In almost every case,AutoGate 264 will make the necessary service request(s) on a time basis(e.g., daily, weekly, monthly, etc.). Subsequent access requests to theNT Node for the updated data may be honored without a specific furtherservice request of the Unisys Node.

FIG. 3 is a diagram showing the relationship of the key softwarecomponents which allow DCOM clients to access enterprise applicationsfor those data elements which automatically updated. The UnisysClearPath IX Server 310 includes both an OS 2200 environment 312 and aWindows NT environment 314. All ClearPath HMP IX Servers 310 includeOn-Line Transaction Processing (OLTP) software that complies with theX/Open model for Distributed Transaction Processing (DTP). This enablesclient/server access to existing OLTP applications as well as allowingdevelopment of new, distributed client/server applications.

The X/Open DTP software provided for the OS 2200 environment 312 isTransIT Open/OLTP, available commercially from Unisys Corporation. TheTransIT Open/OLTP Transaction Manager 317 is the base product for allOpen/OLTP software in the OS 2200 environment 312. It includes: 1) atransaction monitor, which executes and routes transactions, performsload balancing, and recovers transactions after failures and 2) Acommunications resource manager (CRM), which controls communicationsamong distributed applications.

The Open/OLTP Transaction Manager 317 includes interfaces toapplications and to database systems (resource managers), including theDatabase Management System (DMS) and the Relational Database ManagementSystem (RDMS).

The OS2200 Environment also includes an Open/OLTP Heritage ApplicationAccess component 316. This component 316 allows use of existing OS 2200OLTP applications, many without modification, as Open/OLTP serverprograms. This provides an easy way to provide GUI client/server accessto existing applications. These Open/OLTP server programs can beTransaction Processing (TIP), High-Volume Transaction Processing (HVTIP)or other online batch programs (as shown at 318). Tools are provided forformatting the data from the existing program into Open/OLTP bufferformats.

When used with Open/OLTP, the present invention makes it possible toprovide access to the following types of OS 2200 applications from aDCOM environment: 1) Native Open/OLTP applications (local), 2) nativeOpen/OLTP applications that participate in distributed transactions withother platforms running Open/OLTP and BEA TUXEDO software, and 3)Heritage applications that use TIP, HVTIP, and DPS.

Existing transactions can be reused without modification, as long asthey meet the following criteria: 1) Open/OLTP services must use therequest/response model. Conversational services are not supported, and2) Open/OLTP services must use X_C_TYPE or X_COMMON buffers. X_OCTETbuffers are not supported.

The key software components that enable DCOM clients to access Open/OLTPapplications reside in the Windows NT environment 314 of the ClearPathIX server 310. The Open/HTPic software component 320 is middleware whichenables applications in the Windows NT environment to executetransactions against OS 2200 applications that use the Open/OLTPtransaction manager 317. The DGate runtime software component 322(DGate.exe) acts as a conduit between the Windows NT DCOM environment314 and the Open/OLTP environment 312. The DCOM Server softwarecomponent 324 accepts requests from DCOM Clients, repackages theparameters into the format required by the Open/OLTP transaction manager317, and then forwards the parameters over a named pipe to the DGateruntime 322. The DCOM Server 324;could also include a variety ofdistributed objects. The stub software component 326 accepts remoteprocedure calls from object proxies on client PCs and converts them tointerface calls to the DCOM Server application 324.

DCOM Client components 328 reside in a Windows 95 or Windows NTWorkstation environment on a personal computer 315. The DCOM Clientprogram 328 provides a graphical user interface (GUI) for submittingtransaction requests to the DCOM Server 324 and viewing the data itreturns. The Object Proxy software component 330 converts requests fromthe DCOM client 328 to remote procedure calls (RPC) 334. The RPCs 334are subsequently sent across a network 332 to the stub component 326 inthe Windows NT environment 314.

In addition to the DGate runtime components, the present invention alsoincludes a utility called DGateAce (not shown) that simplifies theprocess of defining the DCOM Client and Server programs used with theDGate runtime environment. DGateAce is further described in co-pendingpatent application, Ser. No. ______, entitled, “AN AUTOMATED DEVELOPMENTSYSTEM FOR DEVELOPING APPLICATIONS THAT INTERFACE WITH BOTH DISTRIBUTEDCOMPONENT OBJECT MODEL (DCOM) AND ENTERPRISE SERVER ENVIRONMENTS”, whichis herein incorporated by reference.

FIG. 4 is an illustration of the general software environment. Open/OLTPservices 450 are created by a user on an enterprise server 452, such asa Unisys 2200. These services 450 are capable of operating under anOLTP-style transaction processing system. In a preferred embodiment,this OLTP-style system is X/Open compliant. The service 450 is designedto accomplish a specific task, for example, update a presentation ofairline scheduling and pricing.

Each service is associated with an input view (.V) file 458 whichdefines how the input parameters will be provided to the service 450. Inparticular, the V file 458 indicates where each input parameter islocated in the view file, and the size and type of each input parameter.If a service 450 is to provide output to the user (for example, theupdated scheduling or pricing information), another output view file isrequired to communicate how the information will be presented within theoutput view buffer.

For all services 450 that are to accessed from a particular Windows NTnode 490, the associated view files 458 must be copied (via FTP or othercopy service, shown at 459) to that node 490. Once the view files 458have been successfully copied to the Windows NT node 490, the MakeViewcompiler 460 is used to generate “.hv” files 462.

The WebTx DGateAce software component 472, further described inco-pending application, Ser. No. ______, entitled, “AN AUTOMATEDDEVELOPMENT SYSTEM FOR DEVELOPING APPLICATIONS THAT INTERFACE WITH BOTHDISTRIBUTED COMPONENT OBJECT MODEL (DCOM) AND ENTERPRISE SERVERENVIRONMENTS”, also must have access to the view files 458. DGateAce 472uses the view files 458 to automatically generate files needed for anapplication to operate within a DCOM environment. These files includethe DCOM Server Applcation.exe 470, the Stub.dll 482, and the Proxy.dll484.

The Distributed Component Object Model (DCOM) is a Microsoft model fordistributed object computing. Within the DCOM environment, a remote DCOMClient Application 486 can make a request. The DCOM client 486 can beany type of client, including a Visual Basic client, a C++ client, or aWeb Browser with Active Server Pages (ASP). If the request made by theDCOM client 486 is a request for access to a remote process(interprocess request) the request is routed to proxy.dll 484. Proxy.dll484 is a code segment which receives any client requests targeted for aremote server, and will facilitate the necessary interprocesscommunications. The proxy.dll 484 understands how to communicate withthe Client 486, and also understands how to communicate over aninterface 485 which is shared by two or more processes. The proxy.dll484 “marshals” the request parameters into an independent format so thatthey may be provided by the client process 486 over the COM-basedinterface 485, which conforms with the Microsoft DCOM Model. Thestub.dll 482, which also understands how to communicate over the commoninterface 485, “un-marshals” the parameters into a format that can beunderstood by the DCOM Server Application.exe 470. Thus, the DCOMenvironment allows machines with entirely different architectures (PCs,Workstations, etc.) to communicate using a common interface.

The specifics of the common interface are described in an InterfaceDefinition Language (IDL) 474. The IDL 474 is operated on by theMicrosoft Interface Definition Language (MIDL) compiler 476 to create aset of .c (C) and .h (header) files 478. Then, a second compiler (C++)480 operates on the c and .h files to create the stub.dll 482 and theproxy.dll 484. The proxy.dll 484 is linked to the DCOM ClientApplication.exe 486, and the stub.dll 482 is linked to the DCOM ServerApplication.exe 470.

Once the DCOM Server 470 un-marshals the parameters, the parameters arepackaged into a single buffer and passed to the DGate-Server.dll 468.The DGate-Server.dll 468 and the DGate.exe 466, both of which are thesubject of the present invention, are the modules which “DCOM-enable” anOLTP enterprise server 452 such as the Unisys 2200 System.

FIG. 5 is a flow diagram illustrating how data is updated in the DCOMserver using an automatic service request to an enterprise OLTPenterprise application. The process begins at block 500, with theinitialization of the automatic gateway function. Ordinarily, theupdates will be performed on a timing basis (e.g., daily, weekly,monthly, etc.). The automatic update function experiences the conditionprecedent (e.g., timing signal indicates need for update) at 502. Next,the proxy.dll code in the AutoGate executable determines if the functionis remote, and if so, it marshals parameters, as shown at 504. Theproxy.dll accomplishes this function by converting requests from theAutoGate application to remote procedure calls.

The stub.dll code in the server executable receives the request from theproxy.dll, then un-marshals the parameters, as shown at 506. In otherwords, the stub accepts remote procedure calls from object proxies andconverts them to interface calls to the DCOM server application.

On the Unisys 2200, the request will first be handled by the TransITOpen/OLTP Transaction Manager, available commercially from UnisysCorporation, which is the base product for all Open/OLTP software in theOS 2200 environment. The Open/OLTP Transaction Manager includesinterfaces to applications and to database systems (resource managers),including the Database Management System (DMS) and the RelationalDatabase Management System (RDMS). The service routine on the enterpriseOLTP system eventually sends a response back to the AutoGate executable,which reformats the response into an output buffer and returns theoutput buffer to the TransferToGateway( ) function inAutoGate_Server.dll, as shown at 514.

Next, the TransferToGateway( ) function in DGate_server.dll releases itsconnection to AutoGate.exe and returns the output buffer to the AutoGatecode in the server executable, as shown at 516. The AutoGate code in theserver executable unpacks the output buffer into individual outputparameters, as shown at 518.

The stub.dll code in the server executable then marshals the outputparameters, as shown at 520. Finally, the proxy.dll code in the AutoGateexecutable un-marshals the output parameters into a form that the dataupdate executable can use, as shown at 522. The internal server data isupdated pending user access request at 524.

FIG. 6 is a flow diagram illustrating how to set up an AutoGateapplication. Beginning at 650, the first step in the process is todefine the view files 652. View file definitions show input and outputparameters that will be received and transmitted to/from the On-Linetransaction processing system application. In particular, the view filedefinitions indicate where each input/output parameter is located in thebuffer subtype, and the size and type of each input parameter (e.g.whether the parameter is an 80-byte character string, a long integer,etc). Another output view file definition is required to communicate howthe information will be presented within the output view buffer.

Next, buffer subtype definitions must be installed on the Unisys 2200OLTP enterprise system 654. Open/OLTP users X/Open typed buffers anduser-defined buffer subtypes to define data structures. These structuresensure that applications programs can successfully exchange data, evenwhen they reside on different types of machines. Unisys OLTP-TM2200 VIEWutilities are used to define and install buffer subtypes. When thebuffer subtypes and defined and installed, the Unisys On-LineTransaction Processing Transaction Manager (OLTP-TM2200) encodes anddecodes the buffer data on behalf of the application programs.

Following installation of the buffer subtype definitions on the 2200,the next step in setting up an AutoGate application to write the servicecode, create the server, and append it to the 2200 OLTP 656. The MASutility, a component of the OS2200 TransIT Open/OLTP TransactionManager, is a processor that creates a runstream of Executive ControlLanguage (ECL) statements that call OS2200 tools to build a server. TheMAS utility is used to build extended mode and basic mode servers of allsupported type (HVTIP, TIP, and batch).

Next, the view definition files which were defined on the 2200Enterprise OLTP server are copied (via FTP, or other copy service) tothe Windows NT Node 658. After the view definition files have beencopied to the Windows NT node, the HTPic MAKEVIEW and WebTx WebviewCcompiler are used to generate binary files (.WV and .hv/.V) 660.

FIG. 7 is detailed diagram showing the operation of AutoGate 700.Communication with the enterprise OLTP server is as shown with theissuance of service requests and the receipt of results. Thesetransactions are made automatically in response to the list oftransactions as shown. As discussed above, most of these will be timerelated (e.g., daily, weekly, monthly, etc.), although other conditionsprecedent may also be utilized.

The resultant data presentation after data update is provided by finalpublished html file 702, as shown. This presentation is in the formatprovided by the html template. Final published html file 702 isavailable for access by any of the DCOM users directly from the DCOMserver.

Having thus described the preferred embodiments of the presentinvention, those of skill in the art will readily appreciate that theteachings found herein may be applied to yet other embodiments withinthe scope of the claims hereto attached.

1. In a data processing system having an On-Line Transaction Processing(OLTP) system, the improvement comprising: an automatic gateway whichautomatically updates data within said data processing system byautomatically making a service request of said OLTP system in responseto a condition precedent.
 2. A data processing system according to claim1 wherein a user may access said updated data without generating asubsequent access to said OLTP system.
 3. A data processing systemaccording to claim 2 wherein said condition precedent further comprisesthe passage of an interval of time.
 4. A data processing systemaccording to claim 3 wherein said user accesses said updated data withan industry standard personal computer.
 5. A data processing systemaccording to claim 4 wherein said OLTP system further comprises a Unisys2200 system.
 6. An apparatus comprising: a. an OLTP server forprocessing a service request and providing a result; b. a DCOM serverresponsively coupled to said OLTP server; and c. an automatic gatewaywithin said DCOM server which automatically generates said servicerequest and receives said result in response to a condition precedent.7. A data processing system according to claim 6 wherein said DCOMserver is responsively coupled to said OLTP server via the world wideweb.
 8. A data processing system according to claim 7 further comprisinga user terminal responsively coupled to said DCOM server wherein saiduser terminal accesses said result.
 9. A data processing systemaccording to claim 8 wherein said user terminal further comprises anindustry standard personal computer.
 10. A data processing systemaccording to claim 9 wherein said OLTP system further comprises a Unisys2200 system.
 11. An apparatus comprising: a. means for offering On-LineTransaction Processing of a service request; b. means responsivelycoupled to said offering means for providing a DCOM environment; and c.means located within said offering means for automatically generatingsaid service request in response to a condition precedent.
 12. Anapparatus according to claim 11 wherein said condition precedent furthercomprises elapse of a predetermined time interval.
 13. An apparatusaccording to claim 11 wherein said offering means further comprises aUnisys 2200 system.
 14. An apparatus according to claim 11 wherein saidoffering means is responsively coupled to said providing means via theinternet.
 15. An apparatus according to claim 11 further comprisingmeans responsively coupled to said providing means for providing a userto interface with said providing means.
 16. A method of providingupdated data to a user comprising: a. automatically generating a servicerequest within a DCOM server in response to a condition precedent; b.transferring said service request from said DCOM server to an OLTPserver via a publically available communication system; c. honoring saidservice request within said OLTP service to produce a result; d.transferring said result from said OLTP server to said DCOM server viasaid publically available communication system; e. modifying apresentation to produce said updated data; and f. providing access bysaid user to said updated data via said DCOM server.
 17. A methodaccording to claim 16 wherein said OLTP server is responsively coupledto said DCOM server via the world wide web.
 18. A method according toclaim 17 wherein said access providing step further comprises providingaccess via an industry standard personal computer.
 19. A methodaccording to claim 18 wherein said two transferring steps furthercomprises transferring via the internet.
 20. A method according to claim19 wherein said condition precedent further comprises and elapsed timeperiod.